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Programming with dependent types is a blessing and a curse. It is a 
blessing to be able to bake invariants into the definition of datatypes: we 
can finally write correct-by-construction software. However, this extreme 
accuracy is also a curse: a datatype is the combination of a structuring 
medium together with a special purpose logic. These domain-specific logics 
hamper any effort of code reuse among similarly structured data. In this 
paper, we exorcise our datatypes by adapting the notion of ornament to our 
universe of inductive families. We then show how code reuse can be achieved 
by ornamenting functions. Using these functional ornament, we capture the 
relationship between functions such as the addition of natural numbers and 
the concatenation of lists. With this knowledge, we demonstrate how the 
implementation of the former informs the implementation of the latter: the 
user can ask the definition of addition to be lifted to lists and she will only be 
asked the details necessary to carry on adding lists rather than numbers. Our 
presentation is formalised in a type theory with a universe of datatypes and 
all our constructions have been implemented as generic programs, requiring 
no extension to the type theory. 



1 Introduction 

Imagine designing a library for a ML-like language. For instance, we start with natural 
numbers and their operations, then we move to binary trees, then rose trees, etc. It is 
the garden of Eden: datatypes are data- structures, each coming with its optimised set 
of operations. If, tempted by a snake, we move to a language with richer datatypes, 
such as a dependently typed language, we enter the Augean stables. Where we used 
to have binary trees, now we have complete binary trees, red-black trees, AVL trees, 
and countless other variants. Worse, we have to duplicate code across these tree-like 
datatypes: because they are defined upon this common binarily branching structure, a 
lot of computationally identical operations will have to be duplicated for the type-checker 
to be satisfied. 

Since the ML days, datatypes have evolved: besides providing an organising structure 
for computation, they are now offering more control over what is a valid result. With 



richer datatypes, the programmer can enforce invariants on top of the data-structures. 
In such a system, programmers strive to express the correctness of programs in their 
types: a well typed program is correct by construction, the proof of correctness being 
reduced to type-checking. 

A simple yet powerful recipe to obtain these richer datatypes is to index the data- 
structure. These datatypes have originall y been studied in the context of type the- 
ory under the name of inductive families Dvbier . 1994 . Morris et all 120091 ]. Induc- 
tive families made it to mainstream functional progra mming with Generalised Algebraic 



tive iamilies mad e it to ma instrea m runctional p rogramming witn ueneralisea Algebraic 
Data- Types [Cheney and Hinzel . l200.j IXi et all [2003] , a subset of inductive families for 



which type inferenc e remains decidable. Refinement types [Freeman and Pfenning! . 1 1991 



Swamv et all I2OIIII are another technique to equip data-structures with rich invariants. 



Atkev et al. 201 1 } have sho wn how refinement types relate to inductive families, and 
Bernardv and Lassonl 20111 ] establish a connection with realisability. 

However, these carefully crafted datatypes are a threat to any library design: the same 
data- structure is used for logically incompatible purposes. This explosion of specialised 
datatypes is overwhelming: these objects are too specialised to fit in a global library. 
Yet, because they share this common structure, many o perations on them are extremely 
similar, if not exactly the same. To address this issue, iMcBridd developed ornaments, 
describing how one datatype can be enriched into others with the same structure. Such 
structure-preserving transformations take two forms: one can extend the initial type 
with more information - such as obtaining Maybe^ from Bool or ListA from Nat: 

data Bool : Set where data Maybe [A : Set] : Set where 

Maybe-Orn » . , . / . \ 

Bool 9 true =^ Maybe^ 3 just (a :A) 



false 



nothing 



data Nat : Set where data List [A : Set] : Set where 

m r> List-Orn . . .. 

Nat 3 Listyi 3 nil 

I sue (n: Nat) | cons (a : A)(as : List^) 

Or one can refine the indexing of the initial type by a finer discipline - e.g., obtaining 
Fin by indexing Nat with a bound n: 

data Nat : Set where data Fin (n : Nat) : Set where 

Nat 3 R ^4 rn Fin (n = sucn') 3 fO(n':Nat) 



sue (n : Nat) 



fsuc(n':Nat)(/n:Fin n') 



One can also do both at the same time - such as extending Nat into a List a while 
refining the index to match the length of the list: 

data Nat : Set where data Vec [A : Set] (n : Nat) : Set where 

Nat 3 Ve =^ rn \/ec A (n = 0) 3 nil 

I sue (n: Nat) Vec^ (n = sue n') 3 cons (n' : Nat) (a : A)(vs : Vec^ n') 

Note that we declare datatype parameters [A : Set] in brackets and datatype indices 
(n : Nat) in parentheses. We make equational constraints on the latter only when needed, 
and explicitly. 
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Because of their constructive nature, ornaments are not merely identifying similar 
structures: they give an effective recipe to build new datatypes from old, guaranteeing 
by construction that the structure is preserved. Hence, we can obtain a plethora of new 
datatypes with minimal effort. 

Whilst we now have a good handle on the transformation of individual datatypes, we 
are still facing a major reusability issue: a datatype often comes equipped with a set of 
operations. Ornamenting this datatype, we have to entirely re-implement many similar 
operations. For example, the datatype Nat comes with operations such as addition and 
subtraction. When defining List^ as an ornament of Nat, it seems natural to transport 
some structure-preserving function of Nat to List^, such as moving from addition of 
natural numbers to concatenation of lists: 



(m: Nat) + (n:Nat) 




Nat 


(xs:l\5t A ) ++ (ys :L\st A ) 


: List^ 






+ n 


!->• 


n = 


» nil ++ ys 


H> ys 






(sue to) + n 


!->• 


sue (to + n) 


(cons a xs) ++ ys 


i — y cons a 


(xs + 


+ ys 


(to: Nat) - (n:Nat) 




Nat 


drop (xs:L\st A ) (n:Nat) 


: L\st A 






n 







drop nil n 


i-s> nil 






TO 


!->• 


TO 


drop xs 


l-> xs 






(sue to) — (sue n) 


!->• 


to — n 


drop (cons a is) (sue n) 


i — y dropxs 


n 





More interestingly, the function we start with may involve several datatypes, each of 
which may be ornamented differently. In this paper, we develop the notion of functional 
ornament as a generalisation of ornaments to functions: 



We adapt ornaments to our universe of datatypes Chapman et al. . 20ld ] in Sec- 



tion [3j This presentation benefits greatly from our ability to inspect indices when 
defining datatypes. This allows us to consider ornaments which delete index- 
determined information, yielding a key simplification in the construction of an 
algebraic ornament from an ornamental algebra ; 

• We describe how functions can be transporte d through functional orn aments: 'dele- 
tion' allows us a contrasting approach to iKo and Gibbons! |201l| . internalising 



proof obligations. First, we manually work through an example in Section [2j 
Then, we formalise the concept of functional ornament by a universe construction 
in Section [H Based on this universe, we establish the connection between a base 
function (such as _+ _ and _— _) and its ornamented version (such as, respectively, 
_++- and drop). Within this framework, we redevelop the example of Section [2] 
with all the automation offered by our constructions ; 

In Section [5l we provide further support to drive the computer into lifting functions 
semi-automatically. As we can see from our examples above, the lifted functions 
often follow the same recursion pattern and return similar constructors: with a few 
constructions, we shall remove further clutter and code duplication in our libraries. 
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(ra: Nat) < ( 


n:Nat) 




Bool 


lookup (to : Nat) 


(xs : List ,4) 


: Maybe^ 


to < 







false 


? t lookup TO 


nil 


i-> nothing 


< 


sue n 


!->• 


true 


lookup 


(cons a xs) 


h-> just a 


sue m < 


sue n 


!->• 


m < n 


lookup (sue n) 


(cons a xs) 


1— > lookup n xs 



Figure 1: Implementation of _< _ and lookup 



• Finally, we add a generic gadget to our reusability kit in Section [6j we show how a 
careful use of an adjunction can absorb computation at the index-level - which are 
notoriously difficult to deal with - and replace them by a special-purpose indexed 
family - which is much easier to deal with. 

This paper is an exercise in constructive mathematics: upon identifying an isomor- 
phism, we shall look at it with our constructive glasses and obtain an effective procedure 
that lets us cross the isomorphism. 



We shall write our code in a syntax inspired by the Epigram iMcBride and McKinna 



20041 ] programming language. In particular, we make use of the by ( <= ) and return 



( 1 — y ) programming gadgets, further extending them to account for the automatic lifting 
of functions. For brevity, we write pattern- matching definitions when the recursion 
pattern is evident and unremarkable. Like ML, unbound variables in type definitions are 
universally quantified, further abating syntactic noise. The syntax of datatype definitions 
draws upon the ML tradition as well: its novelty will be presented by way of examples 
in Section All the constructions presented in this paper have been modelled in Agda, 
using only standard inductive definitions and two levels of universes. The formalisation 
is available on Dagand's website. 



2 From _<_to lookup, manually 

There is an astonishing resemblance between the comparison function _ < _ on natural 
numbers and the list lookup function (Fig. [I]). Interestingly, the similarity is not merely 
at the level of types but also in their implementation: their definitions follow the same 
pattern of recursion (first, case analysis on the second element; then induction on the 
first element) and they both return a failure value (false and nothing respectively) in the 
first case analysis and a success value (true and just respectively) in the base case of the 
induction. 

This raises the question: what exactly is the relation between _< _ and lookup? Also, 
could we use the implementation of _< _ to guide the construction of lookup? First, let 
us work out the relation at the type level. To this end, we use ornaments to explain how 
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each individual datatype has been promoted when going from _< _ to lookup: 



< 



lookup 



Nat 
idO Nat 
Nat 



-> Nat 
List-Orn 
■+ List,! 



->■ Bool 
Maybe-Orn 

->• Maybe,! 



Note that the first argument is ornamented to itself, or put differently, it has been 
ornamented by the identity ornament. 

Each of these ornaments come with a forgetful map, computed from the ornamental 
algebra: 

length (as : List a) '■ Nat isJust (m : Maybe^) : Bool 

length nil i-> isJust nothing i— > false 

length (cons a as) h-> sue (length as) isJust (just a) i— > true 

Using these forgetful map, the relation, at the computational level, between _<_ and 
lookup is uniquely established by following the ornamentation of their types. This rela- 
tion is naturally expressed by the following coherence property: 

Vn : Nat.Vx,? : List a- isJust (lookup n xs) = n < length xs 



Or, equivalently, using a commuting diagram: 
Nat x 



lookup 

List,i > Maybe^ 



Nat 



length 
Nat 



.< . 



isJust 
Bool 



Let us settle the vocabulary at this stage. We call the function we start with the base 
function (here, _< _), its type being the base type (here, Nat— > Nat— > Bool). The richer 
function type built by ornamenting the individual pieces is called the functional ornament 
(here, Nat — > List,! — > Maybe^). A function inhabiting this type is called a lifting (here, 
lookup). A lifting is said to be coherent if it satisfies the coherence property. It is crucial 
to understand that the coherence of a lifting is relative to a given functional ornament: 
the same base function ornamented differently would give rise to different coherence 
properties. 

We now have a better grasp of the relation between the base function and its lift- 
ing. However, lookup remains to be implemented while making sure that it satisfies 
the coherence property. Traditionally, one would stop here: one would implement 
lookup and prove the coherence as a theorem. This works rather well in a system like 
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Coq [The Cog Development Team ] as it offers a powerful t heorem proving environment 



It does not work so well in a system like Agda Norelll . 2007 ] that does not offer tactics to 



its users, forcing them to write explicit proof terms. It would not work at all in Haskell 
with GADTs, as it does not have any theorem proving capability. 

However, we are not satisfied by this laborious approach: if we have dependent types, 
why should we use them only for proofs, as an afterthought? We should rather write 
a lookup function correct by construction: by implementing a more precisely indexed 
version of lookup, the user can drive the index- level computations to unfold, hence making 
the type-checker verify the necessary invariants. We believe that this is how it should 
be: computers should replace proofs by computation; humans should drive computers. 
The other way around - where humans are coerced into computing for computers - may 
seem surreal, yet it corresponds to the current situation in most proof systems. 

To get the computer to work for us, we would rather implement the function ilookup: 

ilookup (m : Nat) (us : Vec^ n) : IMaybe^ (m < n) 
ilookup m nil 1-4 nothing 

ilookup (cons a vs) 1— > just a 
ilookup (sue m) (cons a vs) 1— > ilookup m vs 

Where IMaybe^ is Maybe^ indexed by its truth as computed by is Just. It is defined as 
follow^]: 

data I Maybe [A: Set] (b: Bool): Set where 
IMaybe^ true 9just(a:^4) 
IMaybe^ false B nothing 

This comes with the following forgetful map^: 

forgetl Maybe (mba : IMaybe^ b) : {ma : Maybe^) x isJust ma = b 
forgetlMaybe (just a) h-> (just a, true = true) 
forgetlMaybe nothing i-> (nothing, false = false) 

The rational behind ilookup is to index the types of lookup by their unornamented 
version, i.e. the types of _ < _. Hence, we can make sure that the result computed by 
ilookup respects the output of _< _ on the unornamented indices: the result is correct by 
indexing! The type of ilookup is naturally derived from the ornamentation of _< _ into 
lookup and is uniquely determined by the functional ornament we start with. Expound- 
ing further our vocabulary, we call coherent liftings these finely indexed functions that 
ar e correct by cons t ructio n . 

Ko and Gibbonsi [2011 ] use ornaments to specify the coherence requirements for func- 



tional liftings, but we work the other way around, using ornaments to internalise coher- 
ence requirements. From ilookup, we can extract both lookup and its proof of correctness 



1 Note that we have overloaded the constructors of Maybe and IMaybe: for a bi-directional type-checker, 

there is no ambiguity as constructors are checked against their type. 
2 We depart slightly from the convention of calling refl the inhabitant of the identity type a = b: instead 

we shall denote it a = b, hence being explicit about which equation is being proved. 
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without having written any proof term ourselves: 
lookup (to : Nat) (xs : List a) '■ Maybe^ 

lookup to xs i — y 7ro(forgetlMaybe (ilookup to (makeVec xs))) 

cohLookup (n : Nat) (xs : List^) : isJust (lookup n xs) = n < length xs 
cohLookup to xs 1-4 7Ti (forgetl Maybe (ilookup to (makeVec xs))) 

Where makeVec simply turns a list into a vector of the corresponding length. 

As a side comment, remark that the function ilookup is very similar to the more 
familiar viookup function: 

viookup (to : Fin n) (vs :VecA n) : A 

viookup nil 

viookup fO (cons a xs) 1— > a 

viookup (fsuc n) (cons a xs) 1— > viookup n xs 

As we shall see later in Section [6l these two definitions are actually isomorphic, thanks 
to the following equivalence: 

(to: Nat) -> IMaybe^TO < n) = Fin n -)■ A 

Intuitively, we can move the constraint that m<n from the result - i.e. I May be ^(to < n) 
- to the premises - i.e. Finn. This matches our intuition that 

Fin n = (m : Nat) x to < n 

Hence, having implemented ilookup, not only do we obtain lookup and its coherence 
proof, but we also get the traditional viookup function. 

With this example, we have manually unfolded the key steps of the construction of a 
lifting of _ < _. Let us recapitulate each steps: 

• Start with a base function, here _ < _: Nat — > Nat — > Bool 

• Ornament its inductive components as desired, here Nat to Listyi and Bool to 
Maybe^ in order to describe the desired lifting, here lookup : Nat — > List/t — > Maybe^ 
satisfying Vn : Nat.Vxs : List ,4. isJust (lookup n xs) = n < length xs 

• Implement a carefully indexed version of the lifting, here ilookup : (to : Nat) (us : 
Vec^ n) — s> IMaybe^ (to < n) 

• Derive the lifting, here lookup, and its coherence proof, without proving any theo- 
rem 

Besides, the implementation of ilookup is not lost: this function corresponds exactly to 
vector lookup, a function that one would have implemented anyway. 

This manual unfolding of the lifting is instructive: it involves a lot of constructions 
on datatypes (here, the datatypes List^ and Maybe^) as well as on functions (here, the 
type of ilookup, the definition of lookup and its coherence proof). Yet, it feels like a 
lot of these constructions could be automated. In the next Section, we shall build the 
machinery to describe these constructions and obtain them within the type theory itself. 
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data I Desc [/: Set]: Seti where |(D:IDescJ)] >-Set) : Set 

IDesc/ 3 \ar(i:I) [Vart] X 4li 

i 'i pi! x i-n 

'n(5:SET) (T:5^IDesc/) [TI S T] X ^ (s:S) -> {T sj X 

'S(5:Set) (T:5^IDesc/) ['£ S T] X ^ (s:S) x [T s] X 



Figure 2: Universe of inductive families 



3 A universe of datatypes and their ornaments 

In dependently typed systems such as Coq or Agda, datatypes are an external entity: 
each datatype definition extends the type-theory with new introduction and elimination 
forms. The validity of datatypes is guaranteed by a positivity-checker that is part of the 
meta-theory of the proof system. A consequence is that, from within the type theory, 
it is not possible to create or manipulate datatype definitions, as they belong to the 
meta-theory. 



3.1 A closed theory of datatypes 

In our previous work Chapman et al. . 20ld |. we have shown how to internalise induc- 



tive families into type theory. The practical impact of this approach is that we can 
manipulate datatype declarations as first-class objects. We can program over datatype 
declarations and, in particular, we can compute new datatypes from old. This is partic- 
ularly useful to formalise the notion of ornament entirely within the type theory. This 
also has a theoretical impact: we do not need to prove meta-theoretical properties of our 
constructions, we can work in our type theory and use its logic as our formal system. 

Note that our results are not restricted to this setting where datatype definitions 
are internalised: all our constructions could be justified at the meta-level and then 
be syntactically presented in a language, such Agda or Haskell with GADTs. 

Working with an internalised presentation, we can simply avoid these two levels of logic 
and work in the logic provided by the type theory itself. 

For the sake of completeness, let us recall a few definitions and results from our 
previous work. As in previous work, our requirement on the type theory are minimal: 
we will need II-types, and at least two universes. For convenience, we require a 
type of finite sets, which lets us build collections of label^l. We also need a pre-existing 
notion of propositional equality, upon which we make no assumption. We internalise the 
inductive families by a universe construction (Fig. [2]): an indexed datatype is described 
by a function from its index to codes. The codes are then interpreted to build the 



3 We denote finite sets of tagged elements by {'x, 'y, 'z, . . .}. Their elimination principle consists of 
an exhaustive case enumeration and is denoted by {'x H > vx, 'y h-> vy, 'z h4 vz, . . .}. If the tags are 
vertically aligned, we shall skip the separating comma. 
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fix-point: 



data \i [D : I -> I Desc /](«:/): Set where 
LiDi 3 in (a» :!£>*] {jjlD)) 



Inductive types are eliminated by a generic elimination principle: 

iinduction : (D : IDesc I)(P:/iD i — > Set) 

(is : (i : I)(xs : {D i] (jj, D)) -> iAII DPxs^P (in zs)) 
(i :/i D i) -> P 3; 

Where, intuitively, iAII D P xs enforces that all sub-trees of xs satisfy P: this corresponds 
exactly to computing the ind uctive hypothesis nece s sary t o perform th e indu ction step. 
In the categorical literature (rlermida and Jacobs! . 1998 . At key et al. . 201 1 1 . iAII is 
denoted D. 

For readability purposes, we use an informal notation to declare datatypes. This no- 
tation is strongly inspired by Agda's datatype declarations. Note that these definitions 
can always be turned into IDesc codes: when defining a datatype T, we will denote 
T-Desc the code it elaborates to. Similarly, we denote T-elim and T-case the induction 
principle and case analysis operators associated wit h T. These operations can be imple- 



mented by generic programming, along the lines of iMcBride et al.l 2004f |. Formalising 



the elaboration of datatypes definitions down to code is beyond the scope of this paper. 
However, it is simple enough to be understood with a few examples. Three key ideas 
are at play. 

First, non-indexed datatypes definitions follow the ML tradition: we name the datatype 
and then comes a choice of constructors. For example, List would be written and elabo- 
rated as follows: 

data List [A : Set] : Set where 
List^ 3 nil 

I cons (a :A)( as : List a) 



AA A*. 



nil 

'cons 



'nil i-Vl 

'cons H> 'T,A A_. 'var* 



Secondly, indexed datatypes can be defined following the Agda convention: indices 
are constrained to some particular value. For example, Vec could be defined by con- 
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straining the index to be in the nil case and sucra' for some n' : Nat in the cons case: 

data Vec [,4 : Set] (n: Nat): Set where 
Vec ,4 (n = 0) 3 nil 

Vec^ (n = suc n') 3 cons (n' : Uat)(a:A)(vs : Vec^ n') 

i 

-\ * -\ ir , f 'vnil 
AA An. S< , 

[ vcons 

'vnil H> '£ (n = 0) A_. '1 

'vcons H> 'E Nat An'. '£ (n = sue n')A_. 

'£,4A_. 'varn' 

The elaboration naturally captures the constraints on indices by using propositional 
equality. In the case of Vec, we abstract over the index n, introduce the choice of 
constructors with the first 'S and, once constructors have been chosen, we restrict n to 
its valid value(s): in the first case and sucn' for some n' in the second case. 

Thirdly, we can compute over indices: here, we make use of the crucial property that 
a datatype definition is a function from index to IDesc codes. Hence, our notation should 
re flect this abili t y to d efine datatypes as functions on their index. For instance, inspired 



by iBradv et al.l 20041 ] . an alternative presentation of vector would match on the index 



to determine the constructor to be presented, hence removing the need for constraints: 

data Vec [A : Set] (n : Nat) : Set where 
Vec.4 n Nat-case n 

VecA 3 nil 

Vec,4 (sue n) 9 cons (a : A)(vs : Vec,4 n) 
i 

An. 

Nat-case n (A_. IDesc Nat) 
T 

(An. '£y4 A_. 'varn) 



In or der to be fully explicit about computations, we use here the Epigram [McB ride and McKinna 



20041 ] by ( <^= ) programming gadget, which let us appeal to any elimination principle 



with a syntax cl o se to p attern-match ing. However, standard pattern-matching construe- 



Coauandl . Il99l iNorelll . 12007^ would work just as well. Again, we shall write 



tions 

pattern-matching definitions when the recursion pattern is unremarkable. 

Our syntax departs radically from the one adopted by Coq, Agda, and GADTs in 
Haskell. It is crucial to understand that this is but reflecting the actual semantics of 
inductive families: we can compute over indices, not merely constrain them to be what 
we would like. With our syntax, we give the user the ability to write these functions: 
the reader should now understand a datatype definition as a special kind of function 
definition, taking indices as arguments, potentially computing over them, and eventually 
emitting a choice of constructors. 
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As a final example, let us look at the datatype of infinite staircase walks: at each 
step, we can unconditionally go up. Besides, after pattern-matching on the index, we 
can decide to stop on step and, for any non-zero step, we can also go down: 

data Walk (n : Nat) : Set where 

Walk n 3 up (w : Walk (sue n)) 

Walk 3 stop 

Walk (sue n) 9 down (w: Walk n) 



Remark: Note that we have been careful in using equality to introduce constraints here: 
our definition of datatypes is absolutely agnostic in the notion of equality assumed by 
the underlying type theory. For instance, our universe of inductive families cannot be 
used to define equality through the identity type: the identity type would only expose 
the underlying notion of equality to the user. Concretely, the standard definition of the 
identity types is presented and elaborated as follows: 

data \d [ai : A](ag : A) : Set where 

Id ai (d2 = ai) 3 refl 

i 

'£{'refl}{'£(a 2 = oj)A_.'l} 

We have been careful to maintain our presentation of ornaments and functional orna- 
ments similarly equality agnostic. 

3.2 Ornaments 



Originally, iMcBridd presented the notion of ornament for a universe where the indices a 
constructor targets could be enforced only by equality constraints. As a consequence, in 
that simpler setting, computing types from indices was impossible. We shall now adapt 
the original definition to our setting. 

Just as the original definition, an ornament is defined upon a base datatype - specified 
by a function D : I — y I Desc / - and indices are refined up to a reindexing function 
re : J— >■/. The difference in our setting is that, just as the code of datatypes can 
be computed from the indices, we want the ornament to be computable from its J- 
index. Hence, an ornament is a function from j : J to ornament codes describing the 
ornamentation of D (re j): 

om(re:J->I)(D:I->\DescI) : Seti 

orn re D i-)- (j : J) —> Orn re (D (re j)) 

As for the ornament codes themselves, they are similar to the original definition: we 
shall be able to copy the base datatype, extend it by inserting sets, or refine the in- 
dexing subject to the relation imposed by re. However, we also have the J-index in 
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our c ontext: following B rady's insight that inductive families need not store their in- 



dices [Bradv et all 120041 ] , we could as well delete parts of a datatype definition as long 
as we can recover the suppressed bits from the index. Hence, we obtain the following 
codeB 

data Orn [re: J—)- I](D : IDesc /) : Seti where 
- Extend with S: 
Orn re D 3 insert (S : Set)(D + : S -» Orn re D) 
Orn re D <= IDesc-caseD 

- Refine index: 

Orn re ('vari) B 'var (j : re _1 i) 

- Copy original: 
Orn re '1 3 '1 

Orn re ('IIS T) 3 TI (T+ : (s :S) ->■ Orn re (T s)) 
Orn re ('EST) 9 'E (T+ : (s : 5) -)> Orn re (T a)) 

- Delete S: 

| delete (replace: S) (T + : Orn re (T replace)) 

Given an ornament, we can interpret it as the datatype it describes. The implemen- 
tation consists in traversing the ornament code, introducing a '£ when inserting new 
data and computing the ornament at the replaced value when deleting some redundant 
data: 

l(o:om re D)} orn (j : J) : IDesc J 
Mom j >-> intOrn (D (re j)) (o j) 

where 

intOrn (D : IDesc I) (0:QmreD) : IDesc J 

intOrn D insert S D + h> 'E5 As. intOrn D s) 

intOrn ('var (re j)) ('var(invj)) i-> 'varj 

intOrn '1 '1 ^ '1 

intOrn ('US T) (TIT+) ^ 'n5 As. intOrn (T s) (T+ s) 

intOrn ('S5T) ('ST+j h> 'SS As. intOrn (T s) (T + s) 

intOrn ('S 5 T) (delete replace T + ) (->■ intOrn ( T replace) ( T+ replace) 

Note that in the delete case, no '£ code is generated: the set S has been deleted from 
the original datatype. The witness of this existential is instead provided by replace. 

Once again, we adopt an informal notation to describe ornaments conveniently. The 
idea is to simply mirror our data definition, adding from which datatype the ornament 
is defined. When specifying a constructor, we can then extend it with a new element 
using [s :S] or delete an element originally named s by giving its value with [s = value]. 
Some typical examples of extension are presented in Figure [3l 



The inverse image of a function is defined by: 



data \f:A-¥ B](b : B) : Set where 

Z" 1 (b=fa) B \ m (a:A) 
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data List [^4: Set] from Nat where 

List^ 3 nil 

| cons [a : A] (as : List ,4) 

data Vec [A : Set] («: Nat) from List^ where 

VeCyi n 3 nil [q:n = 0] 

I cons [n':Nat][g:n = sue n'](a : A)(vs iVec^n') 

data Fin (n : Nat) from Nat where 

Finn 3 fO [n' : Nat] [q : n = sue n'] 

I fsuc \n! : Nat][g : n = sue n'](fn : Fin n') 



Figure 3: Examples of ornament 



While the definition Vec in Figure mirrors Agda's convention of constraining indices 
with equality, our definition of ornaments lets us define a version of Vec that does not 
store its indices: 

data Vec [A : Set] (n: Nat) from List^ where 
VecA 3 nil 

Vec,4 (sue n') 3 cons (a : A)(vs : Vec^n') 



Note that such a definition was unavailable in the basic presentation McBridel ] . iBradv et al 



2004] call this operation detagging: the constructors of the datatype are determined by 



the index. The definition of Fin given in Figure [3] is also subject to an optimisation: by 
matching the index, we can avoid the duplication of n by deleting n' with the matched 
predecessor and deleting the resulting, obvious proof. Hence, Fin can be further orna- 
mented to the optimised Fin', which makes crucial use of deletion: 



data Fin' (n:Nat) from Fin where 

Fin' 3 [6:0](0-elim b) 
Fin' (sue n) 3 fO [n' = n][q = n = 
I fsuc [n' = n] [q = W 



no constructor 



n](fn : Fin' n') 



Again, this definition was previously unavailable to us. Besides, we are making crucial 
use of the deletion ornament to avoid duplication. IBradv et al.1 20041 ] call this operation 
forcing: the content of the constructors, here n' and the constraint, are computed from 
the index. 

Just as the datatype declaration syntax was elaborated to IDesc codes, this high-level 
syntax is elaborated to ornament codes. The formal description of this translation is 
beyond the scope of this paper. From the definition of an ornamented type T, we will 
assume the existe nce of its corresponding ornament code T-Orn. 

As described by iMcBridd . every ornament induces an ornamental algebra: intuitively, 
an algebra that forgets the extra data, hence mapping the ornamented datatype back to 
its unornamented form. From an ornament O : orn reD, there is a natural transformation 



13 



from the ornamented functor down to the unornamented one, which we denote: 



O-forgetNat :(X:I^ Set)(j : J) [[O] orn jj (X o re) -> \D (re j)} X 

Applied with fiD for X and post-composed with in, this natural transformation induces 
the ornamental algebra: 

O-forgetAlg : (j : J) [[Oj orn jj (p D o re) -)■ pi D (re j) 

In turn, this algebra induces an ornamental forgetful map denoted: 

O-forget :{j:J)^n [<3] orn j^y.D (re j) 

We do not re-implement these functions here: it is straightforward to update the original 
definitions to our setting. 



3.2.1 Algebraic ornaments 

An important class of datatypes is constructed by algebraic ornamentation over a base 
datatype. The idea of an algebraic ornament is to index an inductive type by the result 
of a fold over the original data: from the code D : / — >■ IDesc/ and an algebra a : (i : 
I) — > \D i J X — > X i, there is an ornament that defines a code D a :(i:I) xXi-> IDesc (i : 
I) x X i with the property that: 

[i D a (i,x) ^ (t:/j,Di) x|a|t = i 

We shall indiscriminately use D a to refer to the ornament and the resulting datatype. 
Seen as a refinement type, the correctness property states that fj,D a (i,x ) = \t g 



fiD i\ <\a\j t = x}. The type theoretic construction of D a is described by iMcBride 



We shall not reiterate it here, the implementation be ing essential l y the same for our 



universe. A categorical presentation was also given in lAtkev et al.1 20111 ] in which the 
connection with refinement types was explored. 

Constructively, the correctness property gives us two (mutually inverse) functions. 
The direction fiD a (i,x) —¥ (t: fiD i) x (\a\j t = x relies on the generic D a -forget function 
to compute the first component of the pair and gives us the following theorem: 

coherentOrn:Vi Q :^ J D a (i,a;). H (^"-forget t a ) = x 

This corresponds to the Recomputation theorem of McBridel We shall not reprove it 



here, the construction being similar. In the other direction, the isomorphism gives us a 
function of type: 

(t:fiDi) x flaD t = x^ fiD a (i, x) 
Put in full and simplifying the equation, this corresponds to the following function: 

D a -make :(t: fi D i) fi D a (i, <\a\) t) 

This corresponds to the remember function of McBridel . Again, we will assume this 
construction here. 
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3.2.2 Reornaments 



In this paper, we are interested in a special sub-class of algebraic ornaments. As we 
have seen, every ornament O induces an ornamental algebra O-forgetAlg, which forgets 
the extra information introduced by the ornament. Hence, given a datatype D and an 
ornament Od of D, we can algebraically ornament [0£>] orn using the ornamental algebra 
O p-forgetA lg. We denote the resulting ornament D° D . 



iMcBride calls this object the algebraic ornament by the ornamental algebra. For 
brevity, we call the object D D the reornament of Od- Again, we shall overload D° D to 
denote both the ornament and the resulting datatype. A standard example of reornament 
is Vec: it is the reornament of List-Orn. Put otherwise, a vector is the algebraic ornament 
of List by the algebra computing its length, i.e. the ornamental algebra from List to Nat. 

Reornaments can be implemented straightforwardly by unfolding their definition: first, 
compute the ornamental algebra and, second, construct the algebraic ornament by this 
algebra. However, such a simplistic construction introduces a lot of spurious equality 
constraints and duplication of information. For instance, using this naive definition of 
reornaments, a vector indexed by n is constructed as any list as long as it is of length 
n. 

We can adopt a more fine-grained approach yielding an isomorphic but better struc- 
tured datatype. In our setting, where we can compute over the index, a finer construction 
of the Vec reornament would be as follows: 

• We retrieve the index, hence obtaining n ; 

• By inspecting the ornament List-Orn, we obtain exactly the information by which 
n is extended into a list: if n = 0, no supplementary information is needed and if 
n = sucra', we need to extend it with an a: A. We call this the Extension of n ; 

• By inspecting the ornament List-Orn again, we obtain the recursive structure of 
the reornament by deleting the data already fully determined by the index and its 
extension, and refining the indexing discipline: the tail of a vector of size sue n' is 
a vector of size n' . The recursive structure is denoted by Structure. 

Let us formalise this intuition for any ornament. By the coherence property, we 
know that for any index t : fiD, the reornament t ++ : fiD° D t is isomorphic to the 
comprehension {t + : fi [0] orn j | O-forget t + = t}. Note that the equality constraints are 
introduced only to ensure that t + is built from t through the ornament. Now, in our 
setting, we could enforce this constraint by construction: from the ornament Od and 
i, we can compute the set of valid extensions of t giving a t + such that forgetting the 
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extension gives t back: 



Extension 


(0:Orn re j D) 


(xs:lD}fxD) 




Set 


Extension 


('var(invj)) 


t 




1 


Extension 


'1 


* 


1 — ^ 


1 


Extension 


('n t+) 


^ / 




(s : £)->• Extension (T+ s) (/ s) 


Extension 


('£ T+) 


(s, xs) 




Extension ( T + s) xs 


Extension 


(insert S D+) 


xs 




(s:5) x Extension (D + s) xs 


Extension (delete replace T + 


) (s,xs) 


■ — y 


(q:s = replace j) x Extension T + xs 



The next step consists in building the recursive structure of the reornamented type. 
Again, the recursive structure is entirely described by the ornament together with the 
index t: the ornament gives the recursive structure of t + while the index t specify the 
indexing strategy of the sub-nodes: sub-nodes of t ++ must be indexed by the corre- 
sponding sub-nodes of t. Hence, we obtain the recursive structure of t ++ by traversing 
the ornament definition while unfolding t along the way in order to reach its sub-nodes. 
On a variable, we index by the value specified by the ornament and the t sub-node we 
have reached. On a '£ and insert, we can delete them to avoid information duplication: 
the information is already provided by the index in the case of '£ and by the extension 
in the case of insert. The formal definition is as follows: 

Structure (O :Orn re j D)(xs : [£>] fiD)(e: Extension O xs) : Orn ttq (j, t) \0\ orn 
Structure ('var(invj)) t * i-» 'var (inv (j, t)) 
Structure '1 * * h4 '1 

Structure (TI T+) / e i-4 TI As. Structure (T+ s) (/ s) (e s) 
Structure ('E T + ) (s,xs) e h-> delete s (Structure (T + s) xs e) 
Structure (insert S D + ) xs (s, e) h-> delete s (Structure (D + s) xs e) 
Structure (delete replace T + ) (replace, xs) (s = replace, e) h-> Structure T + xs e 

A reornament is thus the Extension of its index followed by the recursive structure as 
defined by Structure. Thus, we define the associated reornament at index t = in xs:^lD 
by, first, inserting the valid extensions of t with Extension, then, building the recursive 
structure using Structure: 

reornament (O :orn re D) : orn ttq [Oj m 

reornament h4 A(j, in xs). insert (Extension (O j) xs) Ae. 

Structure (O j) xs e 

Applied to the reonarment of List-Orn, this construction gives the fully Brady-optimised 
- detagged and forced - version of Vec, here written in full: 

data Vec [A : Set] (n: Nat) : Set where 
\/ec A 3 nil 

Vec.4 (sue n) 3 cons (a : A)(vs : Vec^ n) 

Note that our ability to compute over the index is crucial for this construction to 
work. Also, it is isomorphic to the datatype one would have obtained with the algebraic 
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ornament of the ornamental algebra. Consequently, the correctness property of algebraic 
ornaments is still valid here: constructively, we get the coherentOrn theorem in one 
direction and the *-make function in the other direction. 

In this Section, we have adapted the notion of ornament to our universe of datatypes. 
In doing so, we have introduced the concept of a deletion ornament, using the indexing 
to remove duplicated information in the datatypes. This has proved useful to simplify 
the definition of reornaments. We shall see how this can be turned to our advantage 
when we transport functions across ornaments. 

4 A universe of functions and their ornaments 

We are now going to generalise the notion of ornament to functions. In order to do this, 
we first need to be able, in type theory, to manipulate functions and especially their 
types. Hence, we define a universe of functions. With it, we will be able to write generic 
programs over the class of functions captured by our universe. 

Using this technology, we define a functional ornament as a decoration over the uni- 
verse of functions. The liftings implementing the functional ornament are related to 
the base function by a coherence property. To minimise the theorem proving burden 
induced by coherence proofs, we expand our system with patches: a patch is the type 
of the functions that satisfy the coherence property by construction. Finally, and still 
writing generic programs, we show how we can automatically project the lifting and its 
coherence certificate out of a patch. 

4.1 A universe of functions 

For clarity of exposition, we restrict our language of types to the bare minimum: a type 
can either be an exponential which domain is an inductive object, or a product which 
first component is an inductive object, or the unit type - used as a termination symbol: 

data Type:SETi where 

Type 3 fj{(D:I-> IDesc/) }->■ (T:Type) 
| fj{(D:I^ IDesc/) (t:7) }x (T:Type) 
| 1 

Hence, this universe codes the function space from some (maybe none) inductive types 
to some (maybe none) inductive types. Concretely, the codes are interpreted as follows: 

[(T:Type)] T ype : Set 

lfA D * H Thype ^ fiDi^ lT] Type 

IA D i }>< ^iType ^ fJ-DiX lTj Type 
[11 Type ^ 1 

The constructions we develop below could be extended to a more powerful universe 
- such as one supporting non-inductive sets or having dependent functions and pairs. 
However, this would needlessly complicate our exposition. 
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Example 1 (Coding _< _). Written in the universe of function types, the type of _< _ 
is: 

type< : Type 

type< i y /^Nat-Desc * }-^/i{Nat-Desc * j-^Bool-Desc * }x 1 

The implementation of _ < _ is essentially the same as earlier, excepted that it must 
now return a pair of a boolean and an inhabitant of the unit type. To be explicit 
about the recursion pattern of this function, we make use of Epigram's by ( •<= ) con- 
struct 



McBride and McKinnal . [2004] : 



< _ : [type<]] Ty p e 
m < n ^= Nat-case n 

m < h-> (false, *) 
m < sue n ^= Nat-elim m 
< sue n i-)- (true, *) 
sue m < sue n *— > m < n 

That is to say: we first do a case analysis on n and then, in the successor case, we 
proceed by induction over m. 

Example 2 (Coding _ + _). Written in the universe of function types, the type of _+_ 
is: 

type+ : Type 

type+ i-> /i{Nat-Desc * }-> /i{Nat-Desc * }-> ^{Nat-Desc *}xl 
Again, up to a multiplication by 1, the implementation of _ + _ is left unchanged: 

+ _ : [type+fljype 

m + n <s= Nat-case m 

+ n (n, *) 

sue m + n i-)- (sucm + n,*) 



4.2 Functional ornament 

From the universe of function types, it is now straightforward to define the notion of 
functional ornament: we traverse the type and ornament the inductive types as we 
go. Note that it is always possible to leave an object unornamented: we ornament by 
the identity that simply copies the original definition. Hence, we obtain the following 
definition: 

data FunOrn (T:Type) :Seti where 

FunOrn (/j{D i }-> T) 3 ^ + {{0 :orn re D) (j : re _1 i) }->■ ( T+ : FunOrn T) 
FunOrn \fi{D i }x T) 3 fi + {(0 :orn re D) (j : re - 1 i) }x ( T+ : FunOrn T) 
FunOrn 1 3 1 



18 



From a functional ornament, we get the type of the liftings by interpreting the ornaments 
as we go along: 

[(T+:FunOrn T)] Fun0m : Set 

[/i + {0(invj)Hr + lFunOrn ^ A* JO] 

[//+{0(invj)}x T+] Fun0rn /i[01 

[IjFunOrn H- 1 



orn FunOr 
orn FunOrr 



We will want our ornamented function to be coherent with the base function we started 
with: for a function / : fj,D — >■ fj,E, the ornamented function / + : fj, [OdJoiti — > A 4 [Osjom 
is said to be coherent with / if the following diagram commutes: 



H [ODiorn 

Op-forget 



r 



f 



V [Oelorn 

O^-forget 



Or, equivalently in type theory: 

Vz+ : ii [Oojorn-/ (O^-forget x+) = O^-forget (/+ x+) 

To generalise the definition of coherence to any arity, we generically define it by induction 
over the universe of functional ornaments: 

Coherence(T+:FunOrn T)(f : [T] TyP e)(/ + : [T + J Fu nOm) : Set 
Coherence (/i+{0 (invj) H T+) / /+ H- 

Vx + : a* [0J orn j. Coherence T+ (/ (forgetOrn x+)) (f + x+) 
Coherence (^ + {0 (inv j) }x T + ) (a?, xs) (x + ,xs + ) H> 

a; = forgetOrn x + x Coherence T + xs xs + 
Coherence 1 * * h >■ 1 



Example 3 (Ornamenting type< to describe lookup). In Section [21 we have identified 
the ornaments involved to transport the type of _< _ to obtain the type of lookup. Let 
us spell them in full here. We need to ornament Nat into List^ and Bool into Maybe^: 

data List [A: Set] from Nat where 

List^ 3 nil 

| cons [a : A] (as : List^) 

data Maybe [A: Set] from Bool where 

Maybe^ 3 just [a: A] 
| nothing 
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From there, we give the functional ornament describing the type of the lookup func- 
tion: 

typeLookup : FunOrntype< 

typeLookup i->- /i + {idC>Nat * }— > ^ + {List-Orn * }— > /i + {Maybe-Orn * }x 1 

The user can verify that [typeLookup]] FunOm gives us the type of the lookup function, up 
to multiplication by 1. Also, computing Coherence typeLookup (_<_) gives the expected 
result: 

A/+ : [typeLookupJpunOrn- 

Vn : Nat.Vxs : List^-isJust (/ + n xs) = n < length xs 

Note that this equation is not specifying the lookup function: it is only establishing a 
computational relation between _<_ and a candidate lifting / + , for which lookup is a 
valid choice. However, one could be interested in other functions satisfying this coherence 
property and they would be handled by our system just as well. 

Example 4 (Ornamenting type+ to describe _++_). The functional ornament of type+ 
makes only use of the ornamentation of Nat into List a'- 

type-H- : FunOrn type+ 

type-H- i — y /i + {List-Orn * }-> /i + {List-Orn * }— s> ^ + {List-Orn * }x 1 

Again, computing [type-H-] FunOrn indeed gives us the type of _++ - while Coherence type++(_ + _) 
correctly captures our requirement that list append preserves the length of its arguments. 
As before, the list append function is not the only valid lifting: one could for example 
consider a function that reverts the first list and appends it to the second one. 

4.3 Patches 

By definition of a functional ornament, the lifting of a base function / : [Tjjype is a 
function /+ of type [T+J 

FunOrn satisfying the coherence property Coherence T + /. To 
implement a lifting that is coherent, we might ask the user to first implement the lifting 
/ + and then prove it coherent. However, we find this process unsatisfactory: we fail to 
harness the power of dependent types when implementing / + , this weakness being then 
paid off by tedious proof obligations. To overcome this limitation, we define the notion 
of Patch as the type of all the functions that are coherent by construction. 

Note that we are looking for an equivalence here: we will define patches so that they 
are in bijection with liftings satisfying a coherence property, informally: 

Patch TT + f = (/ + : [T+] Fun0rn ) X Coherence T+ f /+ (1) 

In this paper, we constructively use this bijection in the left to right direction: having 
implemented a patch / ++ of type Patch T T + f, we will show, in the next Section, how 
we can extract a lifting together with its coherence proof. 

Before giving the general construction of a Patch, let us first work through the _< _ ex- 
ample. After having functionally ornamented _< _ with typeLookup, the lifting function 
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/ + and coherence property can be represented by the following commuting diagram: 



Nat 



id 



Nat 



List a 



List-forget 



Nat 



< 



Maybe^ 

lay be- forget 
Bool 



(2) 



In type theory, this is written as: 

(/+ : Nat x List^ -> Maybe^) x 

Vto: Nat.Vas : List^.m < List-forget as = May be- forget (/ + m as) 

Applying dependent choice, this is equivalent to: 

= (m: Nat) x (n:Nat) x (as :Listx) x List-forget as = n-> 
(ma : Maybe^) x May be- forget ma = to < n 



Now, by definition of reornaments, we have that: 

(as : Listyi) x List-forget as = n = Vec.4 n 
(ma :Maybe^) x Maybe-forget ma = b= IMaybe^fr 



and 



Applying these isomorphisms, we obtain the following type, which we call the Patch of 
the functional ornament typeLookup: 

= (to: Nat) x (n: Nat) x (vs:VecA n) -> IMaybe^ (to < n) 

Which is therefore equivalent to a pair of a lifting and its coherence proof. 

Intuitively, the Patch construction consists in turning all the vertical arrows of the 
commuting diagram (T2J) into the equivalent reornaments, or put in type theory: turning 
the pairs of data and their algebraically defined constraint into equivalent reornaments. 
The coherence property of reornaments tells us that projecting the ornamented function 
down to its unornamented components gives back the base function. By turning the 
projection functions into inductive datatypes, we enforce the coherence property directly 
by the index: we introduce a fresh index for the arguments (here, introducing m and n) 
and index the return types by the result of the unornamented function (here, indexing 
IMaybe^i by the result m<n). 

It is easy to generalise this construction to any functional ornament. For clarity, we 
shall only write the proof for arity one. The generalisation to multiple input and output 
arities is straightforward but tediously verbose. So, from a base function /, we start 
with its lifting and the associated coherence property: 



(/ + :/40 A J orn ^/40 B ] orn )x 



Va+:/4Cy c 



.O s -forget(/+ o + ) 



/(CU-forget a 
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Applying dependent choice, we obtain the following equivalent type: 

= (s:/jA)x (a+:/x [Oyilom) x O^-forget a + = a->(6 + :/j[0 B ] O rn) x OB-forget6 + =/a 

Then, we can simply use the characterisation of a reornament to turn every pair (x + : 
A* [Oxjom) x Ox-forget x + = t into the equivalent inductive type [iX° x t: 

(a:pA) x ^A° A a^nB° B (f a) 

To build this type generically, we simply proceed by induction over the functional 
ornament. Upon an argument (i.e. a fJ- + {0 }—>), we introduce a fresh index and the 
reornament of O. Upon a result (i.e. a ^ + {0 }x ), we ask for a reornament of O indexed 
by the result of the base function. 

Patch (T:Type) (T+:FunOrnT) (/:[Tj Type ) : Set 

Patch (fj{D (re j) y+ T) (^{O (mv j) y+ T+) f ^ 

{x:nD (re j)) ^{iD° (j, x) Patch T T+ (f x) 
Patch (fi{D (re j) }x T) (fi + {0 (invj) }x T+) (x,xs) ^ 

fiD° (j,x) x Patch T T + xs 
Patch 1 1 * i-> 1 

Example 5 (Patch of typeLookup). The type of the coherent liftings of _< _by typeLookup, 
as defined by the Patch of _< _ by typeLookup, computes to: 

(m:Nat)(m + :/xNat id ° Nat to) (n : Nat) (us :// Nat ListA n) -> fi Bool MaybeA (to < n) x 1 

Note that /i Nat ld ° Nat n is isomorphic to 1: all the content of the datatype has been 
forced - the recursive structure of the datatype is entirely determined by its index - 
and detagged - the choice of constructors is entirely determined by its index, leaving 
no actual data in it. Hence, we discard this argument as computationally uninteresting. 
On the other hand, Nat ListA and Bool 1 ^ 6 - 4 are, respectively, the previously introduced 
Vec^ and IMaybe^ types. 

Example 6 (Patch of type+). Similarly, the Patch of _+_ by type+ computes to: 

(TO:Nat)(xs:Nat List ' 4 to) ->• (n : Hat)(ys : Nat ListA to) -> Nat ListA (m + n) Xl 
Which is the type of the vector append function. 

4.4 Patching and coherence 

At this stage, we can implement the i lookup function exactly as we did in Section [2j 
From there, we now want to obtain the lookup function and its coherence certificate. 
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More generally, having implemented a function satisfying the Patch type, we want to 
extract the lifting and its coherence proof. 

Perhaps not surprisingly, we obtain this construction by looking at the isomorphism ([TJ 
of the previous Section through our constructive glasses: indeed, as the Patch type is 
isomorphic to the set of liftings satisfying the coherence property, we effectively get a 
function taking every Patch to a lifting and its coherence proof. More precisely, we 
obtain the lifting by generalising the reornament-induced *-forget maps to functional 
ornaments while we obtain the coherence proof by generalising the reornament-induced 
coherentOrn theorem to functional ornaments. 

We call patching the action of projecting the coherent lifting from a Patch function. 
Again, it is defined by mere induction over the functional ornament. When ornamented 
arguments are introduced (i.e. with n + {0 }— > ), we simply patch the body of the function. 
This is possible because from x + : fj, {Od lorn, we can forget the ornament to compute 
/(forgetOrn x + ) and we can also make the reornament to compute / ++ _(makeAlgOrn x + ). 
When an ornamented result is to be returned, we simply forget the reornamentation 
computed by the coherent lifting: 

patch (T+:FunOrnT) (/: [T] TyP e) (p : Patch T T+ /) : [T+] Fun0r n 
patch Gu+{0 (inv j)HT+) / /++ m- 

Ax + . patch (/ (forgetOrn x + )) 

(/++ (forgetOrn x+) (makeAlgOrn x+)) 
patch (/i + {0 (invj) }x T + ) (x,xs) (x ++ ,xs ++ ) h-> 

(forgetOrn patch T + xs xs ++ ) 
patch 1 * * i-> * 

Extracting the coherence proof follows a similar pattern. We introduce arguments as 
we go, just as we did with patch. When we reach a result, we have to prove the coherence 
of the result returned by the patched function: this is a straightforward application of 
the coherentOrn theorem: 

coherence (T+:FunOrnT) (/: [T] Type ) (p : Patch T T+ /) : Coherence T+ / (patch T+ / p) 
coherence {[i + {0 (invj) ]— >• T + ) f p t- > 

\x + . coherence T + 

(/ (forgetOrn x + )) 

(p (forgetOrn x + ) (makeAlgOrn x + )) 
coherence (fJ, + { O (invj) }x T + ) (x,xs) (x + ,p) \- > 

(coherentOrn x + , coherence T + xs p) 
coherence 1 * * \- > * 

Example 7 (Obtaining lookup and its coherence certificate, for free). This last step is 
a mere application of the patch and coherence functions. Hence, we define lookup as 
follows: 

lookup : pypeLookuplpunOrn 

lookup i-4 patch typeLookup (_<_) ilookup 
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And we get its coherence proof, here spelled in full: 

cohLookup (n : Nat) (xs : List ,4) : May be- forget (7ro(lookup n xs)) = vro(n < List-forget xs) 
cohLookup n xs i-> coherence typeLookup (_<_) ilookup n xs 

Example 8 (Obtaining _++_ and its coherence certificate, for free). Assuming that we 
have implemented the coherent lifting vappend, we obtain concatenation of lists and its 
coherence proof by simply running our generic machinery: 

++ : [type++]FunOn 

++ h-> patch type++ (_ + _) vappend 

coh-H- (xs : List ,4) (ys : List^) : List-forget (vro(a;s ++ ys)) = 7ro((List-forget xs) +(List-forget ys)) 
coh++ xs ys 1 — y coherence type++ (_ + _) vappend xs ys 

Looking back at the manual construction in Section [2 we can measure the progress 
we have made: while we had to duplicate entirely the type signature of lookup and its 
coherence proof, we can now write down a functional ornament and these are generated 
for us. This is not just convenient: by giving a functional ornament, we establish a 
strong connection between two functions. By pinning down this connection with the 
universe of functional ornaments, we turn this knowledge into an effective object that 
can be manipulated and reasoned about within the type theory. 

We make use of this concrete object when we construct the Patch induced by a func- 
tional ornament: this is again a construction that is generic now, while we had to 
tediously (and perhaps painfully) construct it in Section [2j Similarly, we get patching 
and extraction of the coherence proof for free now, while we had to manually fiddle with 
several projection and injection functions. 

We presented the Patch as the type of the liftings coherent by construction. As we have 
seen, its construction and further projection down to a lifting is now entirely automated, 
hence effortless. This is a significant step forward: we could either implement lookup 
and then prove it coherent, or we could go through the trouble of manually defining 
carefully indexed types and write a function correct by construction. We have now 
made this second alternative just as accessible as the first one. And, from a programming 
perspective, the second approach is much more appealing. In a word, we have made an 
appealing technique extremely cheap! 

Finally, we shall reiterate that none of the above constructions involve extending the 
type theory: for a theory with a universe of datatypes, the theory of functional ornaments 
can be entirely internalised as a few generic programs and inductive types. For a system 
lacking a universe of datatypes, this technology would need to be provided at the meta- 
level. However, the fact that our constructions type-check in our system suggests that 
adding these constructions at the meta-level is consistent with a pre-existing meta-theory. 
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< _ : Jtype<]Type ilookup (m : Nat) {vs : Vec^ n) : IMaybe^ [m < n) 

m < n •<= Nat-case n ilookup m vs ■<= Vector-case vs 

m < i— >• (false,*) ilookup m nil H> nothing 

m < sue n -4= Nat-elimm ilookup m (consavs) Nat-elim m 

< sue n i — y (true,*) ilookup (consavs) unjust a 

sue m < sue n m<n ilookup (sucm) (consavs) t— > ilookup m vs 



Figure 4: Implementations of _< _ and ilookup 



5 Lazy programmers, clever constructors 

In our journey from _<_ to lookup, we had to implement the ilookup function. It is 
instructive to put _< _ and ilookup side-by-side (Fig. HJ. First, both functions follow the 
same recursion pattern: case analysis over n/vs followed by induction over m. Second, 
the returned constructors are related through the Maybe ornament: knowing that we 
have returned true or false when implementing _<_, we can deduce which of just or 
nothing will be used in ilookup. Interestingly, the only unknown, hence the only necessary 
input from the user, is the o in the just case: it is precisely the information that has 
been introduced by the Maybe ornament. 

In this Section, we are going to leverage our knowledge of the definition of the base 
function - such as _ < _ - to guide the implementation of the coherent lifting - such 
as ilookup: instead of re-implementing ilookup by duplicating most of the code of _<_, 
the user indicates what to duplicate and only provides strictly necessary inputs. We are 
primarily interested in transporting two forms of structure: 

Recursion pattern: if the base function is a fold fla|) and the user provides us with a 
coherent algebra (3 of a, we automatically construct the coherent lifting (j/3|) of (ja|) 
■ 

Returned constructor: if the base function returns a constructor C and the user provides 
us with a coherent extension C of C, we automatically construct the coherent lifting 
of C 

We shall formalise what we understand by being a coherent algebra and a coherent 
extension below. The key idea is to identify the strictly necessary inputs from the 
user, helped in that by the ornaments. It is then straightforward to, automatically and 
generically, build the lifted folds and values. 

5.1 Transporting recursion patterns 

When transporting a function, we are very unlikely to change the recursion pattern of 
the base function. Indeed, the very reason why we can do this transportation is that the 
lifting uses exactly the same structure to compute its results. Hence, in the majority 
of the cases, we could just ask the computer to use the induction principle induced by 
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the base one: the only task left to the user will be to give the algebra. For clarity 
of exposition, we restrict ourselves to transporting folds. However, the treatment of 
induc tion is essentially th e same, as hinted by the fact that induction can be reduced to 
folds [Fumex et all 12011 ] . 

To understand how we transport the recursion pattern, let us look again at the coher- 
ence property of liftings, but this time specialising to functions that are folds: 



Op-forget 

H D 



P^FunOrn 

T+-forget 

- Plxype 



By the fold- fusion theorem Bird and de Moorl . 1 19971 ] , it is sufficient (but not necessary) 
to work on the algebras, where we have the following diagram: 



\0 D \ T+-forget 

[[Ofllom] PlType 



O d -forget Nat 



\d\ in 



Type 



> [r + ]FunOr 

T+-forget 

- [2lType 



Now, we would like to find an algebra f3 such that its fold gives us a function of the 
Patch type. 

To illustrate this approach, we work through a concrete example: we derive hd : 
List a — > Maybe^ from isSuc : Nat— > Bool by transporting the algebra. For the sake of 
argument, we artificially define isSuc by a fold: 

isSuc(n:Nat) : Bool 

isSuc n i — y (jaisSucD n where 

ctisSuc (xs : [Nat-DescJ Bool) : Bool 

aisSuc '0 !->■ false 

OisSuc ('sue xs) \— > true 

Our objective is thus to define the algebra for hd, which has the following type: 

a M : [List-Desc] Maybe^ -> Maybe^ 



such that its fold is coherent. By the fold- fusion theorem Bird and de Moorl . Il997j |. it 
is sufficient (but not necessary) for a nc j to satisfy the following condition: 

Vms : [List-DescJ Maybe^. 

isJust(ahd ms) = aisSuc (List-forgetNat(|[List-Desc]| isJust ms)) 
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Following the same methodology we applied to define the Patch type, we can massage 
the type of «hd and its coherence condition to obtain an equivalent definition enforcing 
the coherence by indexing. In this case, the natural candidate is: 

a^d : [Vec-Desc] (An'. IMaybe^ (isSuc n')) n — > IMaybe^ (isSuc n) 



This construction generalises to any functional ornament. That is, from an algebra 

Type J -►pi Type 

together with an ornament Ob : orn re D and a functional ornament T + : FunOrn T, the 
type of coherent algebras for a is: 

P:{j:J)(t:nD(rej))^ 

\D° (j, t)j (A(j, t). Patch T (H t) T+) -> 
Patch T(H t)T+ 

It can formally be proved that algebras of this type capture exactly the algebras satisfy- 
ing the coherence condition. Constructively, we get that such a coherent algebra induces 
a coherent lifting, by a mere fold of the coherent algebra: 

lift-fold («:(*:/)-► ID ij (A_. [T] Type ) -> [Tj Type ) 
0: (j:J)(t:fiD(rej))^ 

ID (j, t)j (A(j, t). Patch T (H t) T+) -> 
Patch T (H r+) 
: Patch (re j) }-> T) H H ^ + ) 

lift-fold a $ h-> Ax. Ax++. fl/3[) ^ ++ 

Generalising this idea, we similarly lift induction: 

lift-ind {a:{i:I){xs:\D ij /x Z?) -> 

iAIID(A_.[T] Type )2; S ^[r] Type ) 
(/5:(i : J)(t:fxD (re j))(xs : \D° (j, t)j ^D°) — >■ 

i All (D° (A(j, t). Patch T ((iinduction __ a) t) T+) xs -)• 
Patch T ((iinduction __a) f) T+) 
: Patch (re j) ]->■ T) (iinduction __ a) (j-i + {0 j ]-»• T+) 
lift-ind a /3 i-4 Ax. Ax ++ . iinduction __ /3 x ++ 

Lifting case analysis is now simple, as case a nalysis is a specialisat ion of induction 



where the induction hypotheses are stripped out McBride et all 120041 ] : 
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lift-case {a:{i:I)(xs:\D ij fi D) -> [T] Ty pe) 
0:(j:J)(f.nD(rej)) 

Patch T ((iinduction _ _ (Axs _. a xs)) t) T~ 
: Patch (fi{D(rej)}-> T) 

(iinduction _ _ (Axs _. a xs)) 

lift-case a f3 i— > lift-ind (Axs _. a xs) (Axs _. /3 xs) 



Example 9 (Transporting the recursion pattern of isSuc). We can now apply our generic 
machinery to transport isSuc to hd: in a high-level notation, we would write the command 
of Fig. E^a). To this command, an interactive system would respond by automatically 
generating the algebra, as shown in Fig. 0(b). In the low- level type theory, this would 
elaborate to the following term: 

ihd (vs : VecA n) : IMaybe^ (isSuc n) 

ihd vs H> lift-fold ctjsSuc Oihd where 
«ihd { vs '■ [Vec-DescJ (An'. IMaybe^ (isSuc n')) n) : 

IMaybe^ (isSuc n) 
«ihd 'nil H> {?} 

ajhd ('cons a xs) i-> {?} 

Once again, it is beyond the scope of this paper to formalise the elaboration process from 
the high-level notation to the low-level type theory. The reader will convince himself that 
the high-level notation contains all the information necessary to conduct this task. We 
shall now freely use the high-level syntax, with the understanding that it automatically 
builds a type theoretic term that type-checks. 

Example 10 (Transporting the recursion pattern of _<_). To implement ilookup, we 
use lift-case to transport the case analysis on n and lift-ind to transport the induction 
over m. In a high-level notation, this interaction results in: 

ilookup : Patch type< typeLookup _< _ 

ilookup to rn m n vs j= lift-case 

ilookup to m m nil {?} 

ilookup m to™ (sue n) (cons a vs) j= lift-ind 
ilookup nil {?} 

ilookup (sue m) (sue m m ) nil {?} 



It is crucial to understand here that, in an interactive setting, the user would type in 
the 4= command together with the action to be carried out and the computer would 
automatically generate the resulting patterns. 
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Example 11 (Transporting the recursion pattern of _+_). In order to implement 
vappend, we can also benefit from our generic machinery. We simply have to instruct 
the machine that we want to lift the case analysis used in the definition of _ + _ and we 
are left filling the following goals: 



5.2 Transporting constructors 

Just as the recursive structure, the returned values often simply mirror the original 
definition: we are in a situation where the base function returns a given constructor and 
we would like to return its ornamented counterpart. Informing the computer that we 
simply want to lift the constructor, the computer should fill in the parts that are already 
determined by the original constructor and ask only for the missing information, i.e. the 
data freshly introduced by the ornament. 

Remember that, when implementing the coherent lifting, we are working on the reor- 
naments of the lifting type. Hence, when returning a constructor-headed value, we are 
building an inhabitant of a reornament. When defining reornaments in Section I3.2.2| 
we have shown that, thanks to deletion ornaments, a reornament can be decomposed in 
two components: 

• first, the extension that contains all the extra information introduced by the orna- 



• second, the recursive structure of the refined datatype, which defines the type of 
the arguments of the constructor 

And no additional information is required: all the information provided by indexing with 
the unornamented datatype is optimally used in the definition of the reornament. There 
is absolutely no duplication of information. 

This clear separation of concern is a blessing for us: when lifting a constructor, we 
only have to provide the extension and the arguments of the datatype, nothing more. 
In term of implementation, this is as simple as: 



vappend : Patch type+ type++ _ + _ 

i ''ft rn. 

vappend m xs n ys -4= litt-case 

vappend nil n ys {?} 

vappend (sue m) (cons a xs) n ys {?} 



ment ; 



lift-constructor (xs : \D (re j)\ \i D) 




(in xs, t) 



(n + {Oj}x T+) 



lift-constructor xs e a t ++ i-> (in (e, a), t ++ ) 
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Example 12 (Transporting the constructors of isSuc). Let us finish the implementation 
of hd from isSuc. Our task is simply to transport the true and false constructors along 
the Maybe ornament. In a high-level notation, we would write the command shown 
in Fig. [2c). The interactive system would then respond by generating the code of 
Fig. [5jd). The 1 goals are trivially solved, probably automatically by the system. The 
only information the user has to provide is a value of type A returned by the just 
constructor. 

Example 13 (Transporting the constructors of _< _). In the implementation of ilookup, 
we want to lift the returned true and false to the Maybe ornament. In a high-level 
notation, this would be represented as follows: 

ilookup : Patch type< typeLookup _< _ 

ilookup m m m n vs 4= lift-case 

ilookup m m m nil h5 nothing *[*] 



m 


m m 


n vs 


m 


m m 


nil 


m 


m m 


(sue n) (cons a 








(sue n) (cons a 



ilookup m m m (sue n) (cons a vs) 4= lift-ind 

■ I I „ / % , s lift 

ilookup 

ilookup (sue m) (sue m m ) (sue n) (cons a vs) {?} 

As before, in an interactive setting, the user would instruct the machine to execute the 
command ^5 and the computer would come back with the skeleton of the expected 
inputs. Finishing the implementation of ilookup is now one baby step away, which we 
should jump straightaway: 

ilookup : Patch type< typeLookup _< _ 

ilookup m m m n vs <= lift-case 

ilookup m m m nil h5 nothing *[*] 



rn 


m m 


n 


vs 


m 


m m 





nil 


rn 


m m 


(sue n) 


(cons a 








(sue n) 


(cons a 



ilookup m m m (sue n) (cons a vs) 4= lift-ind 

ilookup (sue n) (cons a vs) ^5justa[*] 

ilookup (sue rn) (sue m m ) (sue n) (cons a vs) \-t ilookup m m m n vs 



Example 14 ([Transporting the constructors of _ + _). We can also benefit from the 
automatic lifting of constructors to fill out the cons case of vector append. We instruct 
the system that we want to lift the sue constructor and get the following goals as a 
result: 

vappend : Patch type+ type++ _ + _ 

i lift ,. fi 

vappend m xs n ys 4= htt-case 

vappend nil n ys {?} 

vappend (sue rn) (cons a xs) n ys h5 cons {?:yl}[{?}] 
It is then straightforward to, manually this time, conclude the implementation of 
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vappend: 

vappend : Patch type+ type++ _ + _ 

vappend to xs n ys 

vappend nil n ys 

vappend (sue to) (cons a xs) n ys 



lift ... 

<= lift-case 

h-> ys 

i — y cons afvappend to xs n ys] 



6 Removing index-level computations 

For a seasoned programmer, the type of i lookup might appear rather unconventional: 

ilookup: (to : Nat) (us : Vec^i n) — > IMaybe^ (to < n) 

Indeed, lookup in a vector is traditionally given the following type: 

vlookup: (to : Fin n)(vs : Vec,4 n) — s> A 

The issue with the first presentation is that the return type is indexed by a computed 
value, to < re. This means that, provided that we have an x : IMaybe^ k and we want to 
return it, we must first make sure that the computation of to < re has unfolded to k, where 
k might be a value (such as true or false) or a suspended computation (such as sucm < n). 
Making sure that this index-level computation unfolds correctly can be cumbersome at 
best, and sometimes simply impossible. One then has to manually rewrite the goal using 
proofs. Again, this pollutes the function definition with computationally unnecessary 
details. 

On the other hand, the second presentation requires absolutely no special care to 
indexes, nor any need for proofs. The key difference is in handling the constraint that 
m must be less than the length of the vector. In the first case, we make no assumption 
on to as an input and then constrain the result to be meaningful if to < n and pointless 
otherwise (by definition of I Maybe). In the second case, we restrict the input to to be 
less than n (by stating that m: Fin re) and therefore the result is always meaningful. 

6.1 From ilookup to vlookup, manually 

It is intuitively clear that these two presentations are equivalent. However, sometimes 
it is easier to work with the first (e.g. because we use our lifting machinery that, by 
design, unfolds the indexed computation as wanted) or with the second (e.g. the recursion 
pattern we want does not mirror the one of the indexed computation) . Let us look closer 
at this equivalence, factoring out the vector that has no influence here: 

(to: Nat) -» IMaybe^ (to< n) = F\nn^A 

While this seems to suggest an adjunction, it is not clear what the functors are. Rewriting 
the equation more abstractly help to see clearer: 

1 Nat -> IMaybe^ (_ < n) = Fin n -4 A 
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Where 1 is the map from Nat to 1 and P —> Q is defined as (x : Nat)— >P x — >Q x. 
Having done that, we can make a more informed guess on the right adjoint: it is the 
functor AX : Nat -> Set. Am : Nat. X o (_ < n). 

Now, as for the left adjoint, we must extract a functor that would map 1 Nat to Fin n. 
The semantics of Fin n is of great help here: intuitively, an inhabitant of Fin n is a number 
m : Nat such that m<n, or put otherwise 

Fin re = {m € Nat | m < re} 

As we have seen in Section f3. 2. 11 these two presentations are equivalent: seen as the al- 
gebraic ornament by the algebra of _< n, Fin n can be decomposed as a num ber (as com- 



puted by Nat a< -forget) and a proof (as computed by coherentOrn). Following I Atkev et al 



20111 ] . we translate this into category, obtaining that Finn = X(_ <n ) o 1 Nat. This sug- 



gests the following equivalences: 

1 Nat -> IMaybe^ (_ < n) = Fin n ->• A 

= £(_<„) 1 Nat -> IMaybe^ 

The second and third line are indeed equivalent: the third line maps predicates over Bool, 
which might seem as more general than the second line, however in the false, IMaybe 
simplifies to 1. Hence, the only interesting case happens when the index is true, in which 
case IMaybe simplifies to . 

With this more abstract presentation, it should be clear what the left adjoint must 
be: it is £(_ <n \. Now we have to check that £(_ <n ) is indeed left adjoint to _o (_< n): it 
is actually true in any locally cartesian closed-category (LCCC). Hence, a fortiori, this 
is true in type theory, as type-theories are a model of LCCCs. 

6.2 Reindexing and algebraic ornaments 

In all generality, we prove the following equivalence: 

(m:nD)->LiE (l\a\) m) = nD a n->nEn 

The proof is straightforward, following the intuition we gave above: 

(m : fj, D) —> fi E ((\a\) m) = D — > [j,E o (\a\) (abstract the index) 

^^lfiD^/iE (S/H-o/) 
= fj, {D a } om -> [iE (coherence of algebraic ornament) 

Through our constructive glasses, this categorical equivalence correspond to two rather 
interesting functions: in one direction, rIAdjoint transforms a function with index-level 
computation into one with a stronger premise ; in the other direction, IrAdjoint turns a 
function with strong premises into one with index-level computation. The implementa- 
tion is absolutely unsurprising: we translate the categorical proof into its corresponding 
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constructive operation, i.e. the coherentOrn theorem and the -make function: 

rlAdjoint (/ : (i :/)(*: \i D i) -> y. E (f, fla& i)) 

(i:/)(i:Ii)(f:4D a ] m (i,x)) : /iS (i, i) 
rlAdjoint / i x t x ^ subst (Ax. /x E (sym (coherentOrn i 2; (/ (Z? a -forget 

lrAdjoint( ff :(2:/)(a;:X2)(P:/zp a l om (t, x)) (t, x)) 

(i:I)(t:fiD i) : fiE{i,<\a\) t) 
IrAdjoint git g (D a -make t) 

We should finally add that this construction is in no sense restricted to the functions 
computed by Patch: the relation we have established and made concrete here can be used 
for any function. Of general interest is the function IrAdjoint: instead of tediously un- 
folding the computation t\a\) , the programmer can instead build the alternative function 
without having to care about the recursion pattern introduced by a. 

In our framework, the rlAdjoint is more interesting: our clever constructors make it 
easy to unfold the index-level computation, however, in practice, one will rather use the 
equivalent function using richer data-types. Hence, our user can implement the Patch 
using our machinery while still getting the more convenient function. 



Example: from ilookup to viookup. Using the gadget we have just developed, we can 
now obtain viookup automatically from the definition of ilookup: 

viookup (to : Fin n) (vs :Vec^ n) : A 

viookup m vs 1 — y rlAdjoint (Am. ilookup to vs)* true m 



7 Related work 



Our work is an extension of the work of lMcBridd on ornaments, originally introduced to 



organise datatypes according to their common structure. This gave rise to the notion 
of ornamental algebras - forgetting the extra information of an ornamented datatype 
- and algebraic ornaments - indexing a datatype according to an algebra. This, in 
turn, induced the notion of algebraic ornament by ornamental algebras, which is a key 
ingredient for our work. 

However, for simplicity of exposition, these ornaments had originally been defined on 
a less index-aware universe of datatypes. As a consequence, computation over indices 
was impossible and, therefore, deletion of duplicated information was impossible. A 
corollary of this was that reornaments contained a lot of duplication, hence making the 
lifting of value from ornamented to reornamented datatype extremely tedious. 

Our presentation o f algebraic o r name nt has been greatly improved by the categorical 



model developed by lAtkev et al.1 [20 111 ] : the authors gave a conceptually clear treat- 
ment of algebraic ornament in a Lawvere fibration. At the technical level, the authors 
connected the definition of algebraic ornament with truth-preserving liftings, which are 
also used in the construction of induction principles, and op-reindexing, which models 
S-types in type theory. 
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Whilst the authors did not explicitly address the issue of transporting functions across 
ornaments, much of the infrastructure was implicitly there: for instance, lifting of folds 
is a trivial specialisation of induction. Also, the characterisation of the fix-point of an 
algebraic ornament as op-reindexing of the fold is a key ingredient to understanding 
index-level computations and assimilate them at the term level. 

In th eir work on realisability and parametricity for Pure Type Systems, Bernardy and 
Lasson Bernardv and Lassonl . l201l| have shown how to build a logic from a programming 
language. In such a system, terms of type theory can be precisely segregated based on 
their computational contribution and their logical contribution. In particular, the idea 
that natural numbers realise lists of the corresponding length appears in this system 
under the guise of vectors, the reflection of the realisability predicate. The st rength of 
the realisability interpr etation is that it is naturally defined on functions: while iMcBride 
and lAtkev et al.1 20111 ] only consider ornaments on datatypes, their work is the first, to 
our knowledge, to capture a general notion of functions realising - i.e. ornamenting - 
other functions. 

Following the steps of Bernardy, Ko and Gibbons! 2011 ] adapted the realisability in- 
terpretation to McBride's universe of datatypes and explored the other direction of the 
Patch equivalence, using reornaments to generate coherence properties: they describe 
how one could take list append together with a proof that it is coherent with respect 
to addition and obtain the vector append function. Their approach would shift neatly 
to our index-aware setting, where the treatment of reornaments is streamlined by the 
availability of deletion. 

However, we prefer to exploit the direction of the equivalence which internalises co- 
herence: we would rather use the full power of dependent types to avoid explicit proof. 
Hence, in our framework, we simultaneously induce list append and implicitly prove its 
coherence with addition just by defining vector append. Of course, which approach is 
appropriate depends on one's starting point. 

Moreover, our universe of functions takes a step beyond the related work by support- 
ing the mechanised construction of liftings, leaving to the user the task of supplying 
a minimal patch. Our fr amework could easily be us e d to mechanise the rea lisability 
predicate constructions of Bernardv and Lasson 2011 ] , Ko and Gibbons! 2011 ] . 



8 Conclusion 



In this paper, we have developed the notion of functional ornament and shown how one 
can achieve code reuse by transporting functions along a functional or nament. To this 



end, we have adapted McBride's ornaments to our universe of datatypes [Chapman et al. 



2010f | . This gave us the ability to compute over indices, hence introducing the deletion 
ornament. D eletion ornaments are a key ingredient to the internalisation of Brady's 
optimisation [Br adv et all 120041 ] over inductive families. In particular, this gave us a 
simpler implementation of reornaments. 

We then generalised ornaments to functions: from a universe of function type, we 
define a functional ornament as the ornamentation of each of its inductive components. 
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A function of the resulting type will be subject to a coherence property, akin to the 
ornamental forgetful map of ornaments. We have constructively presented this object, 
by building a small universe of functional ornaments. 

Having functional ornaments, this raises the question of transporting a function to its 
ornamented version in such way that the coherence property holds. Instead of asking our 
user to write cumbersome proofs, we defined a Patch type as the type of all the functions 
that satisfies the coherence property by construction. Hence, we make extensive use of 
the dependently typed programming machinery offered by the environment: in this 
setting, the type-checker, that is the computer, is working with us to construct a term, 
not waiting for us to produce a proof. 

Having implemented a function correct by construction, one then get, for free, the lift- 
ing and its coherence certificate. This is a straightforward application of the equivalence 
between Patch type and the set of coherent functions. These projection functions have 
been implemented in type theory by simple generic programming over the universe of 
functional ornaments. 

To further improve code reuse, we provide two clever constructors to implement a 
Patch type: the idea is to use the structure of the base function to guide the imple- 
mentation of the coherent lifting. Hence, if the base function uses a specific induction 
principle or returns a specific constructor, we make it possible for the user to specify 
that she wants to lift this element one level up. This way, the function is not duplicated: 
only the new information, as determined by the ornament, is necessary. 

To conclude, we believe that this is a first yet interesting step toward code reuse for 
dependently typed programming systems. With ornaments, we were able to organise 
datatypes by their structure. With functional ornaments, we are now able to organise 
functions by their structure-preserving computational behaviour. Besides, we have devel- 
oped some appealing automation to assist the implementation of functional ornaments, 
without any proving required, hence making this approach even more accessible. 



8.1 Future work 

Whilst we have deliberately chosen a simple universe of functions, we plan to extend it 
in various directions. Adding type depend ency (n- and S-t ypes) but also non indu ctive 
sets is a necessary first step. Inspired by Bernardv 201 it ] but also Miguel 2001 ], we 



would like to add a parametric quantifier: in the implementation of i lookup, we would 
like to mark the index A of Vec^ and IMaybe^ as parametric so that in the cons a case, 
the a could automatically be carried over to just a. 

The universe of functional ornaments could be extended as well, especially once the 
universe of functions has been extended with dependent quantifiers. For instance, we 
want to consider the introduction and deletion of quantifiers, as we are currently doing 
on datatypes. Whilst we have only looked at least fixed points in this paper, we also 
want to generalise our universe with greatest fixed points and the lifting of co-inductive 
definitions. 

Further, our framework relies crucially on the duality between a reornament and its 
ornament presentation subject to a proof. We cross this isomorphism in both directions 
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when we project the lifting from the coherent lifting. In practice, this involves a traversal 
of each of the input datatypes and a traversal of each of the output datatypes. However, 
computationally, these traversal are identities: the only purpose of these terms is at the 
logical level, for the type-checker to fix the types. We are looking at transforming our 
library of clever constructor into a proper domain-specific language (DSL). This way, 
implementing a coherent lifting would consists in working in a DSL. Projecting the lifting 
and its coherence proof would then be the work of an optimising compiler that would 
compute away the useless translations. 

Finally, much work remains to be done on the front of usability: for convenience, we 
have presented some informal notations for datatypes, their ornaments and an extension 
of Epigram programming facility with liftings. A formal treatment of these syntaxes and 
of their elaboration to the low-level type theory is underway. 
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(a) Request lifting of algebra (user input): 



ihd (vsiVec^n) : IMaybe^ isSuc n 
ihd ^ lift-fold 

{?} 

(b) Result of lifting the algebra (system output): 

ihd (vs : Vec^ n) : IMaybe^ (isSuc n) 

ihd ^ lift-fold where 

«ihd (vs '■ [Vec-DescJ (An'. IMaybe^ (isSuc n')) n) : IMaybe^ (isSuc n) 

aihd 'nil {?} 

aihd ('cons a xs) {?} 

(c) Request lifting of constructors (user input): 

ihd (vs : Vec^ n) : IMaybe^ (isSuc n) 

ihd <J= lift-fold where 

CKjhd (vs : [Vec-DescJ (An'. IMaybe^ (isSuc n')) n) : IMaybe^ (isSuc n) 

a\hd 'nil ^ {?} 

a\hd ('cons a xs) h$ {?} 

(d) Result of lifting constructors (system output) 

ihd (vs : Vec^ n) : IMaybe^ (isSuc n) 

ihd ^ lift-fold where 

^ihd (vs : [Vec-DescJ (An'. IMaybe^ (isSuc n')) n) : IMaybe^ (isSuc n) 

a ihd 'nil ^ nothing {?:!} [{?:!}] 

aihd ('consaxs) ^5 just {? : A} [ {? : 1} ] 

(e) Type-checked term (automatically generated from (d)): 

ihd (vs : Vec^ n) : IMaybe^ (isSuc n) 

ihd vs i V lift-fold ai s s uc aihd where 

«ihd (vs : [Vec-DescJ (An'. IMaybe^ (isSuc n')) n) : IMaybe^ (isSuc n) 

a ihd 'nil i-s> lift-constructor 'nil {?:!} {?:!} * 

«ihd ('cons a xs) i-> lift-constructor ('sue n) {?:^4} {?:!} * 



Figure 5: Guided implementation of ihd 
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